Oracle TimesTen In-Memory Database推奨されたプログラミングの実行

パフォーマンスを最大にするための推奨事項

この章では、次の推奨事項について説明します。

パフォーマンス重視の直接リンクされたアプリケーションの実行

全SQL文の事前準備

ディスクへの書込み頻度の制御

問合せに対する適切な索引の作成

showplanを使用した、問合せに適切な索引が使用されていることの検証

自動コミットの無効化および定期的なコミット

C/C++（ODBC）とJava（JDBC）のパフォーマンス

データ・ロード後の索引作成による大量データ・ロードの高速化

TTClassesの使用（OLEDB / ADO / サード・パーティのミドルウェアの回避）

パフォーマンス重視の直接リンクされたアプリケーションの実行

TimesTenのダイレクトODBCおよびJDBCドライバを使用し、データ・ストアと同一のマシンでアプリケーションを実行すると、TimesTenのパフォーマンスを容易に最大限にできます。他のマシンのアプリケーションが、クライアント/サーバー機能を使用してTimesTenデータ・ストアにアクセスすることは可能ですが、ネットワーク通信量のオーバーヘッドによってパフォーマンスが大幅に低下します。

レプリケーションおよびCache Connect to Oracleを使用すると、クライアント/サーバー・アクセスのオーバーヘッドが発生することなく、データへのローカル・アクセスが可能になります。

注意: クライアント/サーバー・アーキテクチャで動作するTimesTenは、ダイレクト・メモリー・モードのTimesTenほど高速ではありませんが、十分に高速です。TimesTen Client/Serverアプリケーションは、従来のクライアント/サーバー・データベースに接続されたアプリケーションよりもパフォーマンスが優れています。特に、TimesTenは従来のデータベースと比較すると、非常に優れたスループットを実現できます。

次の状況では、アプリケーションは、クライアント/サーバー接続でTimesTenデータ・ストアに接続することを検討する必要があります。

TimesTenデータ・ストアが存在するホストとは違うホストで、アプリケーションを実行する必要がある場合。

32-bitのクライアント・アプリケーションが64-bitのTimesTenデータ・ストアに接続する必要があるが、32-bitのクライアント・アプリケーションを64-bitで再コンパイルできない場合。アプリケーションがTimesTenのデータ・ストアと同一のホストに再配置する（または再配置できる）が、64-bitのモードで再コンパイルできない場合は、TimesTen共有メモリー・プロセス間通信（SHMIPC）の使用を検討することをお薦めします。SHMIPCは、クライアント/サーバーのデータ・ストアの接続性に関して、TCP/IP接続のパフォーマンスを大幅に改善します。

TimesTen Client/Server接続が多数必要なシステムを設計した場合は、各データ・ストア接続でサーバー・ホスト上のオペレーティング・システムのリソースを消費していることに注意する必要があります。サーバー・ホストのサイジングおよびオペレーティング・システムのチューニングに、この要素を含める必要があります。

全SQL文の事前準備

最高のパフォーマンスを得るには、複数回実行するSQL文をすべて事前に準備しておく必要があります。これはすべてのリレーショナル・データベースにあてはまります。ただし、TimesTenをきわめて高速なトランザクション率で使用する場合、文のコンパイルに必要な時間が、文の実行に必要な時間の数倍に達する可能性もあります。文の事前準備に加えて、それらの入力パラメータと出力列も事前にバインドしておく必要があります。

ODBCのユーザーは、SQLPrepare関数を使用して文を事前に準備します。

TTClassesのユーザーは、TTCmd::Prepare()メソッドを使用して文を事前に準備します。

JDBCのユーザーは、PreparedStatementクラスを使用して文を事前に準備します。

通常、TimesTen問合せオプティマイザには、効率的な問合せ計画を選択する大変優れた機能があります。ただし、効率的な計画を選択するには、複雑な問合せに含まれる表に関する追加情報が必要となります。

オプティマイザが効率的な計画を選択するには、データ・ストア統計を使用する必要があります。表について、行の数と列の値のデータ分布を把握することにより、オプティマイザはより高い確率で、その表にアクセスするための効率的な問合せ計画を選択できます。

通常、データ・ストアのすべての表の統計を更新してから、これらの表にアクセスする問合せを準備することをお薦めします。

行を挿入する前に表の統計を更新すると、表に行が含まれない（または数行のみが含まれる）ことを想定して、問合せが最適化されます。後で表に数百万行を移入して問合せを実行すると、表に含まれている行が数行だった場合には効果的に動作していた計画が、非常に低速になることもあります。

したがって、表の統計は、データとともにロードした後で、問合せを準備する前に更新する必要があります。

統計の更新の詳細は、『Oracle TimesTen In-Memory Database APIおよびSQLリファレンス・ガイド』のTimesTen組込みプロシージャに関する章にあるttOptUpdateStatsおよびttOptEstimateStatsの説明を参照してください。同じ章のその他のttOpt*組込みプロシージャの説明も非常に有用です。

ディスクへの書込み頻度の制御

通常のアプリケーションでは、データ・ストアにある程度の永続性が必要です。つまり、ハードウェアまたはソフトウェアの障害が原因でシステムがクラッシュした場合に、データ・ストアへの最新の更新が失われないことが要求されます。DurableCommits接続属性を使用してTimesTenを構成する方法がいくつかあります。

１つ目のオプションは、接続属性DurableCommits=1でTimesTenデータ・ストアに接続することです。これによって、その接続でのコミットのたびにトランザクション・ログがディスクにフラッシュされ、その結果、アプリケーションは完全な永続性を保持します。ただし、DurableCommits=1を設定すると、アプリケーションの書込みパフォーマンスは大幅に低下します。ただし、データ・ストアへの同時書込みが多数ある場合には、DurableCommits=1によって優れた全体的なスループットを実現できます。

2番目のオプションは、TimesTenデータ・ストアが一杯になった場合は常に、インメモリーのトランザクション・バッファをディスクへフラッシュできるようにすることです（デフォルトの動作、つまりDurableCommits=0）。このオプションを使用すると、ディスクへの書込みは絶対に必要なときにのみ発生し、トランザクションによってディスクへの書込みが妨げられないため、最高のパフォーマンスを実現できます。ただし、この方法を採用するアプリケーションでは、（トランザクションのインメモリー・ログ・バッファのサイズ以上は減らせないという事実以外）トランザクションの永続性のレベルを正確に判断できません。

DurableCommits=0を使用したアプリケーションの場合、ttDurableCommit組込みプロシージャを使用すると、アプリケーション開発者は、TimesTenのインメモリー・ログ・バッファがディスクにフラッシュされるタイミングを正確に設定できるため、適切なレベルの永続性およびパフォーマンスを明示的に管理できます。アプリケーションは、ディスクへの同時書込みを発生させる（または発生させない）トランザクションを選択できます。これにより、アプリケーションで慎重にパフォーマンスとデータ永続性のバランスを取ることができます。アプリケーションによっては、特定の時間隔でttDurableCommitをコールする必要があります。そのため、1回に失われる可能性があるフラッシュされていないログ・バッファの保証は、100ミリ秒間のみです。2つの口座間の振替など、その他のアプリケーションでは、データ・ストアを永続状態にする必要があります。

TimesTenのレプリケーションまたはTimesTenからOracleへの更新の伝播（あるいはその両方）を使用すると、DurableCommit設定の選択に関係なく、トランザクションの永続性のレベルを追加できます。

問合せに対する適切な索引の作成

データ・ストアのパフォーマンスを向上させるために、索引をどれくらい作成すればよいのかを判断するのは、少し困難なことです。作成した索引が少なすぎると、頻繁に行うデータ・ストア操作の一部が通常よりも遅くなります。作成した索引が多すぎると、索引の更新に余分な時間が必要になるために、挿入/更新/削除の操作に通常よりも時間がかかります。

TimesTenの表と索引のスキーマを設計する際に、考慮すべき問題がいくつかあります。

ハッシュ索引とTツリー索引の2種類の索引があります。適切にチューニングされたハッシュ索引は、完全一致検索について、対応するTツリー索引より高速ですが、ハッシュ索引は範囲問合せに使用できません（Tツリー索引は、完全一致および範囲検索に加えて、ORDER BY、GROUP BY、またはDISTINCTを含むSQL問合せなどのソートにも使用できます）。

各表の主キーは、ハッシュ索引を使用して索引付けされます。

ハッシュ索引はチューニングが必要です。CREATE TABLE文のPAGES= オプションを使用して、想定される表のサイズを指定します。想定される表の行数を256で割り、その値をページ数として指定します。索引用に指定するページ数が多すぎると、領域を浪費します。行数が少なすぎると、バケットがオーバーフローするため、ハッシュ索引のパフォーマンスが低下します。ALTER TABLEを使用すると、必要に応じて、後から主キー索引のサイズを変更できます。

Tツリー索引を持たない表の全表スキャンのパフォーマンスは、Tツリー索引（任意のTツリー索引）を含めることによって改善できます。この場合、表スキャンがその索引の列を参照しなくてもパフォーマンスを改善できます。これは意外なことですが、簡単に証明されます。そのため、アプリケーションの全表スキャンで参照されるあらゆる表に、Tツリー索引を1つ以上作成することを検討する必要があります。

3つの列のハッシュ索引は、3つの列すべてが完全に一致する検索でのみ使用できます。Tツリー索引の列の任意の先行接頭辞は、完全一致検索に使用できます。

ハッシュ索引とTツリー索引のいずれかを使用できる場合、ハッシュ索引の等価条件のパフォーマンスはTツリー索引よりも良くなります。ただし、ハッシュ索引はTツリー索引よりも多くの領域を必要とします。

例：

SELECT ... FROM T1 WHERE COL1 = ? AND COL2 = ?

状況1:

T1に次の2つの索引が存在します。

ハッシュ索引: （COL1、COL2）

Tツリー索引: （COL1、COL2、COL3）

この場合、いずれの索引もこの問合せへの応答に使用できます。

WHERE句の列がハッシュ索引の列と完全に一致するため、ハッシュ索引を使用できます。また、WHERE句の列がTツリー索引の列の先行接頭辞（最初の2つ）であるため、Tツリー索引を使用して問合せに応答できます。

ハッシュ索引のほうが高速なため、TimesTenオプティマイザはハッシュ索引を選択します。

状況2:

T1に次の2つの索引が存在します。

ハッシュ索引: （COL1、COL2、COL3）

Tツリー索引: （COL1、COL2）

この場合、Tツリー索引のみをこの問合せへの応答に使用できます。

ハッシュ索引の列の1つ（COL3）が問合せのWHERE句に指定されていないため、ハッシュ索引は使用できません。ただし、Tツリー索引の列は、問合せのWHERE句の列と完全に一致します。

TimesTenオプティマイザはTツリー索引を選択します。

状況3:

T1に次の2つの索引が存在します。

ハッシュ索引: （COL1）

Tツリー索引: （COL3、COL1、COL2）

この場合、ハッシュ索引のみをこの問合への応答に使用できます。

ハッシュ索引のすべての列が問合せのWHERE句に含まれるため、ハッシュ索引を使用できます。問合せのWHERE句に追加の列があるため、問合せの結果が返される前に、ハッシュ索引から読み込まれるすべての行に、COL2 = ?条件が適用されます。

Tツリー索引は最初にCOL3でソートされ、問合せはCOL3を参照しないため、Tツリー索引は使用できません。

TimesTenオプティマイザはハッシュ索引を選択します。

状況4:

T1に次の2つの索引が存在します。

ハッシュ索引: （COL1、COL2、COL3）

Tツリー索引: （COL3、COL1、COL2）

この場合、いずれの索引もこの問合せへの応答に効率的には使用できません。ただし、Tツリー索引は全表スキャンに使用できます。

前述の状況2と同じ理由で、ハッシュ索引は使用できません。問合せの行（COL1、COL2）は索引の先行接頭辞ではないため、Tツリー索引は使用できません。

いずれの索引も使用できないため、データ・ストアは表スキャンを実施して問合せに応答する必要があります（一時索引を作成する場合もあります）。その結果、問合せのパフォーマンスは低下します。

これらの例からわかるように、最も頻繁に行われるデータ・ストアへの問合せに基づいて、どの索引を作成するかを慎重に選択する必要があります。

適切な索引の作成の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の、文のチューニングと索引の使用の項、およびハッシュ索引またはTツリー索引の適切な選択の項を参照してください。

showplanを使用した、問合せに適切な索引が使用されていることの検証

特定の問合せの実行が予想よりも低速である場合、TimesTenのオプティマイザが、問合せの応答に最適な問合せ計画を選択していない可能性があります。問合せによって生成される計画を確認する方法については、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の計画の表示の項を参照してください。

自動コミットの無効化および定期的なコミット

ODBCおよびJDBCのデフォルトでは、データ・ストアへのすべての接続は自動コミットが有効になっています。つまり、各SQL文がそれぞれのトランザクションでコミットされます。自動コミットを無効にして、単一のトランザクションで複数のSQL文を明示的にコミットすると、アプリケーションのパフォーマンスを大幅に改善できます。これは、バルク挿入またはバルク削除などの大規模な処理で特に有効です。（TTClassesの場合、自動コミットはデフォルトで無効になっています。）

ただし、単一のトランザクションにあまりにも多くの操作を含めると、ロックが長時間保持されるため、システム全体の同時実行性が低下するおそれがあります。通常、バルク挿入/更新/削除の操作は、数千行ごとにコミットすると、最も効率良く処理できる傾向があります。

C/C++（ODBC）とJava（JDBC）のパフォーマンス

TimesTen固有のAPIはODBCです。TimesTenのJava JDBCドライバは、TimesTenのODBCドライバの最上部に構成されたタイプ2ドライバです。このため、TimesTenのODBCドライバを使用したC/C++アプリケーションは、TimesTenのJDBCドライバを使用したJavaアプリケーションよりも少し高いパフォーマンスを実現できます。最高レベルのパフォーマンスが必要なアプリケーションは、TimesTenのODBCドライバを使用して開発する必要があります。

注意: TimesTenのJDBCドライバはきわめて高速です。TimesTenのJDBCのパフォーマンスも、他のデータベースのJDBCのパフォーマンスより大幅に優れています。TimesTenのJDBCドライバは、TimesTenのODBCドライバよりもわずかに低速ですが、その差は重要です。

ODBCとJDBCとの予想されるパフォーマンス結果の差は、実行した問合せの種類（SELECTまたはUPDATE/INSERT/DELETE）およびトランザクションの構成（読込みから書込みまで）によって異なります。パフォーマンスに影響を与える要素は、次のとおりです。

準備した文のバインドされたパラメータの数 - バインドされたパラメータの数が増加すると、Javaアプリケーションのパフォーマンスが低下する傾向があります。

SELECT文によって返される列の数 - SELECT文によって返される列の数が増加すると、Javaアプリケーションのパフォーマンスが低下する傾向があります。

パラメータおよび列の型 - データ型を構成するバイト数が大きくなると、通常、JDBCでは低速になります。

基本的に、Javaアプリケーションは、アプリケーションとデータ・ストア間で転送されるデータ量が増加すると、パフォーマンスが低下します。ODBCとJDBCとの予想されるパフォーマンスの差異の詳細は、オラクル社カスタマ・サポート・センターにお問い合せください。

次に、Javaアプリケーションのパフォーマンスに影響を与える、Javaで継承されるその他の問題を示します。

1）JVMのガベージ・コレクション - JavaアプリケーションではJVMのガベージ・コレクション中にレスポンス時間が増加します。このガベージ・コレクションによって、高パフォーマンスのリアルタイム・アプリケーションで一貫したパフォーマンスを保障するのが困難な場合があります。JVMのガベージ・コレクションを慎重にチューニングすることは、こうしたパフォーマンス上の問題を最小化または排除するために不可欠です。

Javaのランタイム・メモリー管理 - Javaのランタイム・メモリー管理サブシステムの設計によって、隠しデータのコピーが発生する場合があります（特にStringオブジェクトの場合）。Javaのヒープ領域を十分に確保しておく必要があります。

過度にマルチスレッド化されたJavaアプリケーションのスケール - TimesTenでは、過度にマルチスレッド化されたJavaアプリケーションは、予想したほどにはスケール変更できません。この原因の1つは、オペレーティング・システムのスレッド・スケジューラよりもJVMのスレッド・スケジューラの設計です。多くの場合、複数のJVMを使用すると、単一のJVMで多数のスレッドを実行するよりも全体的なパフォーマンスを改善できます。

特定のJVMは他のJVMよりも高速です。慎重に選択肢を判断してください。

大量の結果セットを返す場合は、SELECT文でMAXROWSオプションを使用してください。

データ・ロード後の索引作成による大量のデータ・ロードの高速化

アプリケーション設計によっては、データをロードした後にTツリー索引を作成すると、データのロードに要する時間を最小化できます。この場合、次の順序で操作を実行する必要があります。

表にデータをロードします（ロギングを無効化するかデータ・ストア・レベルのロックを使用すると、表のロード操作中のパフォーマンスが改善されます）。

Tツリー索引を作成します。

統計を更新します。

問合せを準備します。

これは大量のデータ・ロード操作（たとえば数百万行）を実行する場合のみを対象としていることに注意してください。

TTClassesの使用（OLEDB / ADO / サード・パーティのミドルウェアの回避）

多くのサード・パーティのデータベース・インタフェース・パッケージでは、データ・ストアのパフォーマンスにペナルティが課せられます。これらのインタフェースは、特定のアプリケーションでパフォーマンスが重要でない場合には使用できますが、ユーザーはパフォーマンスのトレードオフが発生することを認識している必要があります。

これらのサード・パーティのパッケージは低速なことがあるため、TimesTenではTTClassesという独自のC++ ODBCラッパー・クラスを開発しました。これはTimesTenに含まれています。TTClassesの詳細は、『Oracle TimesTen In-Memory Database TTClasses ガイド』を参照してください。